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PREFACE 


Decision  Support  Systems  (DSS)  are  combinations  of  computer  hardware  and  software 
designed  to  assist  decision-makers  in  making  complex  decisions.  DSS  extend  the  capabilities  of 
management  information  systems  (MIS)  primarily  by  providing  additional  analytical  capability  for 
examining  the  impacts  of  alternative  decisions.  This  report  documents  a  continuing  research  effort 
which  began  under  the  Improved  Operation  Management  Techniques  (IOMT)  Research  Program 
and  has  been  continued  through  support  of  CECW-OM.  The  current  effort,  documented  herein, 
served  to  modify,  upgrade,  maintain,  and  support  the  Corps  of  Engineers  Operations  and 
Management  Budget  Decision  Support  System  (COMBDSS)  in  the  FY  95  budget  cycle.  The 
COMBDSS,  as  it  was  used  in  the  95  budget  cycle,  is  an  extension  of  the  COMB  DSS  prototype 
previously  developed  for  the  Operations,  Construction,  and  Readiness  (OCR)  Division  to  support 
the  FY  94  budget. 

This  research  project  was  a  team  effort.  Two  pivotal  members  of  the  team  are  Dave 
Harmon  and  Dennis  Kern  (CECW-OM).  Dave  Harmon  is  the  primary  user  of  the  original 
prototype  COMB  DSS  used  by  HQUSACE  in  the  FY  94  budget  submittal  and  spent  many  hours 
helping  the  research  team  develop  and  improve  the  system.  Dave  is  also  the  primary  author  of  the 
Division  ABS  software  system,  which  is  used  by  Division  personnel  to  rank  and  submit  the  annual 
Operations  and  Maintenance  Budget.  Michael  R.  Walsh,  CECW-IWR-R,  was  the  project  technical 
monitor  and  provided  the  project  team  invaluable  support,  technical  guidance,  and  advanced  testing. 
Planning  and  Management  Consultants,  Limited  (PMCL)  provided  technical  support  under  contract 
to  the  Institute  for  Water  Resources  (IWR.)  Craig  A.  Strus  was  PMCL’s  project  manager  and 
provided  technical  support  to  the  project  team.  Russ  E.  Robinson  (PMCL)  developed  the  data 
import  and  export  mechanisms  and  performed  system  testing.  Richard  M.  Males,  RMM  Technical 
Services,  Inc.,  a  subcontractor  to  PMCL,  was  intensely  involved  in  this  work  effort  and  performed 
the  majority  of  system  modifications  required  for  the  FY  95  budget  cycle. 

This  report  was  written  by  Craig  A.  Strus,  Richard  M.  Males,  and  Michael  R.  Walsh. 
Comments  about  this  report  are  encouraged  and  should  be  directed  to  Michael  R.  Walsh,  CEWRC- 
IWR,  Casey  Building,  Fort  Belvoir,  VA  22060  (703)  355-3087. 
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I.  INTRODUCTION 


OVERVIEW  OF  REPORT 

The  organization  of  this  report,  in  addition  to  the  preceding  preface,  is  as  follows.  This 
chapter  provides  an  overview  of  the  research  events  leading  up  to  this  work  effort  and  discusses  the 
research  objectives.  Chapter  II  discusses,  in  more  detail,  previous  efforts  leading  up  to  current 
COMBDSS  system.  Chapter  III  discusses,  in  detail,  system  changes  made  in  this  work  effort. 
Chapter  IV  summarizes  the  work  effort,  providing  design  team  insights  on  system  strengths, 
weaknesses,  and  future  directions  of  DSS  tools  in  the  Corps  O&M  Arena. 


BACKGROUND  AND  EVOLUTION 

The  Corps  of  Engineers  Operation  and  Management  Budget  Decision  Support  System 
(COMB  DSS)  was  originally  developed  as  part  of  the  Improvement  of  Operations  and  Management 
Techniques  (IOMT)  research  program.  The  objective  of  the  IOMT  program  is  to  (1)  reduce  costs 
while  increasing  the  safety  and  efficiency  of  operations  and  maintenance  management,  (2)  enhance 
the  utility  of  O&M  assets  such  as  locks,  dams,  and  vessels,  and  (3)  address  the  economic  and 
budgetary  issues  in  the  O&M  function.  The  COMB_DSS  was  envisioned  as  a  demonstration 
project  oriented  towards  providing  decision  support  capabilities  for  the  existing  O&M  budget 
development  process,  at  the  HQ  level,  specifically  to  provide  assistance  in  financial  analysis  and 
development  of  rankings  for  the  work  functions  of  the  annual  budget  submittals. 

The  COMB  DSS  was  developed  for  HQUSACE  as  a  prototype  system  and  was  written  in 
R:Base  3.x/4.0,  a  relational  database  management  system  and  product  of  Microrim,  Inc.  R:Base 
was  chosen  because  of  its  rapid  prototyping  capabilities  and  adherence  to  ANSI  SQL  (Structured 
Query  Language)  standards.  The  prototype  system  actually  used  in  the  1994  budget  submittal. 
Because  the  COMB  DSS  was  successful,  IOMT  funded  a  prototype  Division  decision  support 
system  (COMBDSS-D)  to  provide  similar  capabilities  at  the  Division  level.  The  COMB  DSS  D 
was  similarly  developed  and  used  in  conjunction  with  ORD’s  development  of  the  1995  budget 
submittal.  The  design  team  used  the  COMB  DSS  as  the  starting  point  for  the  COMB  DSS-D,  a 
recently  completed  work  effort.  Additional  enhancements  made  to  the  Division  prototype 
(COMB  DSS-D)  in  that  work  effort  were  folded  into  the  COMB  DSS  improvements  in  this  work 
effort. 


The  COMB_DSS  is  a  separate  system,  operating  upon  information  from  the  Automated 
Budget  System’s  (ABS)  Corps-wide  budget  database.  Within  the  ABS,  Districts  and  Divisions 
generate  and  rank  work  function  packages.  The  completed  ABS  database  eventually  resides  under 
Oracle  on  a  CDC  computer  in  Vicksburg,  MS.  The  ABS  supports  the  submittal  of  annual  budget 
information  for  review  and  appropriation  at  the  District,  Division,  and  Headquarters  levels. 
Information  is  transferred  from  the  ABS  database  to  the  COMB  DSS  database.  Analysis  of  the 
budget  is  then  performed  within  the  COMB  DSS  including  work  function  prioritization  and 
ranking.  Information  is  then  passed  back  to  the  ABS.  Thus,  the  ABS  works  as  the  primary  data- 
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gathering  and  correction  system  at  the  District  and  Division  level,  and  the  COMBDSS  is 
specialized  for  analysis  and  ranking  functions.  It  is  intended  that,  over  time,  the  decision  support 
systems  of  the  COMB  DSS  be  folded  into  enhanced  ABS  capabilities  in  a  single  system. 


PROJECT  OBJECTIVES 

The  project  objectives  were  to:  (1)  perform  bug  fixes  uncovered  during  system  application 
in  the  FY  94  budget  cycle,  (2)  provide  a  more  intuitive  and  enhanced  menu  system,  (3)  enhance 
system  capabilities  to  better  support  the  budget  submittal  process  at  the  Headquarters  level,  and  (4) 
provide  system  support,  as  required,  to  Headquarters  personnel. 
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II.  COMB  DSS  BACKGROUND 


CONCEPTUAL  OVERVIEW 

During  the  evolution  of  the  first  COMB_DSS  prototype,  the  concept  of  a  scenario  was 
developed.  A  scenario  can  be  considered  a  subset  of  work  functions  containing  a  likeness  (e.g.,  a 
set  of  work  functions  from  the  same  Division  or  a  set  of  work  functions  with  the  same  feature  cost 
code).  The  COMB  DSS  prototype  allowed  the  user  to  build,  modify,  and  delete  scenarios,  thereby 
providing  a  means  for  managing  ’groups’  of  work  functions.  Additionally,  by  storing  scenarios,  a 
finite  audit  trail  of  analysis  events  is  created.  The  COMB  DSS-D  contains  three  types  of 
scenarios:  Primary,  Composite,  and  SQL. 

Primary  scenarios  were  designed  as  the  basic  method  of  grouping  work  functions  together 
for  future  reference,  reporting,  and  financial  analysis.  A  two  page  data  entry  form  was  developed 
to  allow  primary  scenario  selection  criteria  to  be  entered  and  edited.  The  first  field  in  the  primary 
scenario  screen  insists  that  a  unique  scenario  name  be  assigned.  Some  of  the  constraints,  applied  to 
work  functions  in  the  creation  of  a  primary  scenario,  are  as  follows: 

•  Appropriation  (e.g.,  E,  F,  or  C)  REQUIRED 

•  Low  use  navigation  flag 

•  A  range  of  OCE  (Bogus)  ranks 

•  A  range  of  output  measures  (really  condition  index) 

•  Two  user  defined  variable  ranges  (used  in  ranking) 

•  A  minimum  cost  on  the  work  function 

•  A  cumulative  cost,  above  which  (or  below  which)  no  more  work  functions  are 
obtained  for  the  scenario 

•  Whether  or  not  the  cumulative  cost  should  be  calculated  in  ascending  or  descending 
order. 

•  Constrain  to  particular  Division  code(s). 

•  Constrain  to  particular  Class(es)  of  work. 

•  Includes  and  excludes  of  particular  CWIS  numbers,  OCE  ranks,  and  Feature  Cost 
Codes. 

A  ’composite’  scenario  is  an  integration  of  primary,  composite,  or  SQL  scenarios,  built 
through  an  ’intersect’,  ’union’,  or  ’subtraction’  process.  A  Union  (U)  scenario  process  will  provide 
the  union  of  work  functions  contained  in  each  scenario  labeled  as  U  (i.e.,  any  work  function  in  any 
U  process  is  in  the  composite.)  An  intersect  I  scenario  process  gives  the  intersection  of  work 
functions  contained  in  each  scenario  labeled  as  I  (i.e.,  the  work  function  must  be  present  in  all  I 
work  functions  to  be  included  in  the  composite.)  The  S  scenario  process  subtracts  work  functions 
in  the  S  scenario  processes  from  the  work  functions  in  the  I  scenario  processes.  The  S  process 
cannot  be  combined  with  the  U  process,  only  with  I  processes.  Note  that  I  and  U  processes  are 
also  mutually  exclusive.  When  S  and  I  are  processed  jointly,  the  I  scenario  processes  are  handled 
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first,  and  then  the  S  scenario  processes  are  subtracted.  Scenario  Composite  scenario  processes  are 
detailed  in  Figure  II- 1 . 
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FIGURE  II-2 
SCENARIO  TABLES 


The  COMBDSS-D  also  contains  an  ’SQL’  (pronounced  ’see-quel’)  scenario  capability, 
which  enables  the  user  to  build  an  ad-hoc  scenario  with  consideration  of  selection  criteria  that  are 
not  available  through  the  primary  scenario  data  entry  forms.  The  user  can  enter  an  SQL  where 
clause,  which  generates  a  constraint  on  any  field  or  combination  of  fields  in  the  table  containing 
available  work  functions.  Once  created,  an  SQL  scenario  can  be  joined  with  primary  or  composite 
scenarios  through  the  union,  intersection,  or  subtraction  processes  discussed  and  depicted  previously. 
The  tables  used  to  store  all  three  types  of  scenario  information  for  retrieval  at  a  later  time  and  the 
relationships  between  them  are  depicted  in  Figure  II-2. 

Note  that  when  a  scenario  is  run,  the  results  (the  set  of  work  functions  that  satisfy  the 
selection  criteria  for  the  scenario)  are  stored  in  the  TEMPSCEN  table.  After  a  scenario  is 
evaluated,  it  can  be  permanently  ’stored’  in  a  work  function-scenario  matrix  file  stored  outside  of 
R:Base  and  cost  summaries  are  saved  in  five  summary  tables  shown  on  the  right  of  Figure  II-3. 


The  concept  of  scoring  was  also  introduced  in  the  original  COMB  DSS  prototype.  The 
scoring  capability  allowed  the  COMB_DSS  user  to  assign  a  score  to  a  scenario.  In  this  process, 
each  work  function  for  a  given  scenario  is  assigned  the  scenario’s  score.  Because  a  work  function 
may  be  in  more  than  one  scenario  (overlapping  scenarios),  the  lowest  score  (1  is  better  than  2)  is 
assigned  to  the  work  function.  The  entire  set  of  work  functions  are  then  ’dumped’,  by  division, 
score  (ascending),  and  division  rank  (ascending)  to  an  ASCII  file.  This  file  is  then  read  by  a 
custom  program  which,  for  a  given  score  and  division,  creates  a  stack  containing  descending 
Division  ranks.  These  Division  stacks  are  then  placed  into  a  single,  common  stack,  with  each 
Division  chosen  randomly,  to  arrive  at  a  final  OCE  rank  that  preserves,  in  as  much  as  possible,  the 
Division  rank  (i.e.,  the  original  Division  rank  is  only  disturbed  by  the  inclusion  of  the  score).  The 
scenario/scoring  approach  is  not  possible  under  the  use  of  previous  HQUSACE  tools,  and  its  advent 
into  the  budget  process  has  saved  the  Corps  money  in  terms  of  time  and  resources. 
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HQUSACE  PROTOTYPE 


The  original  IOMT  work  effort  focussed  on  the  development  of  decision  support  tools  to 
better  support  the  annual  budget  submittal  process.  A  system  concept  was  developed  and  was 
followed  by  multiple  software  'prototypes’,  in  which  a  prototype  was  built,  reviewed  by 
Headquarters  personnel,  and  modified  based  upon  the  review.  This  process  is  termed  rapid 
application  development  (RAD),  or  iterative  prototyping,  in  which  a  system  is  built,  reviewed,  and 
modified  to  better  serve  the  client  needs,  after  a  relatively  brief  design  phase. 

In  August  of  1992,  the  COMBDSS  prototype  was  applied  to  the  FY  1994  budget.  Once 
the  Division  analysis  was  complete,  the  Division  databases  were  aggregated  into  a  Corps-wide 
database,  which  served  as  the  starting  point  for  Headquarters  analysis.  A  number  of  problems  were 
uncovered  in  the  Corps- wide  database,  which  were  resolved  with  the  COMB  DSS  prototype’s 
quality  assurance  data  checks.  Following  database  corrections,  the  actual  analysis  began. 

To  ensure  that  the  system  operated  as  intended,  personnel  from  the  design  team  provided  on¬ 
site  support.  As  the  analysis  process  evolved,  a  number  of  system  bugs  were  uncovered  and 
corrected.  Additionally,  a  number  of  rollup  reports  were  written  to  provide  information  that  was 
not  ’on  menu’  (built)  into  the  system.  In  retrospect,  the  on-site  support  proved  invaluable  as:  (1) 
the  system  would  not  have  been  successful  otherwise,  and  (2)  it  was  shown  that  system 
modifications  could  be  made  in  a  short  period  of  time. 


DIVISION  PROTOTYPE 

A  follow  up  research  effort  was  funded  by  IOMT  to  explore  the  potential  for  DSS  in  the 
budget  process  at  the  Division  level.  The  design  team  saw  the  COMB  DSS  prototype  as  the 
starting  point  for  Division  analysis  and  felt  that  the  system  could  be  modified  to  support  Division 
requirements.  The  Ohio  River  Division  (ORD)  was  selected  as  a  test-bed  for  implementation,  and 
an  initial  meeting  took  place  in  March  1993.  The  meeting  involved  a  discussion  of  system 
requirements,  which  were  broken  into  five  primary  components,  as  follows: 

(1)  Quality  Assurance  -  checks  on  the  District  data 

(2)  Scenario  Analysis  -  financial  summaries  of  the  data 

(3)  Division  Ranking  -  development  of  the  Division  ranks 

(4)  Impact  Analysis  -  determination  of  impacts  of  HQ  and  OMB  decisions 

(5)  Data  Transfers  -  data  input  and  output  to/from  ABS  format  files 

In  the  development  of  iterative  prototypes,  each  of  the  five  components  were  evolved  to 
meet  Division  needs.  All  of  the  COMB_DSS  capabilities  were  retained  for  the  Division  prototype, 
but  only  a  subset  of  them  were  actually  used  in  the  budget  submittal  process. 

The  ranking  procedure  used  in  the  HQ  version  of  COMB_DSS  was  demonstrated  to 
Division  personnel,  but  did  not  meet  ORD  ranking  requirements.  The  HQ  ranking  method  operates 
at  an  aggregate  level,  ranking  scenarios,  as  discussed  in  the  previous  section.  ORD,  with  fewer 
work  functions  to  handle,  and  a  determination  to  permit  Districts  to  develop  their  own  rankings  in 
so  far  as  possible,  set  ’cutoff  ranks,  below  which  District  rankings  were  accepted  automatically. 
ORD  then  examines  and  ranks  each  work  function  from  level  2  through  waivers.  This  was  done  in 


7 


a  two-day  group  meeting  at  which  representatives  of  the  Districts  were  present.  Computer  support 
was  necessary  to  capture  the  assigned  ranks  developed  during  this  meeting,  and  to  display  the 
financial  consequences  (allocation  of  dollars  by  District,  within  funding  level),  of  the  ranking. 
Accordingly,  an  entire  set  of  routines  to  provide  'real-time’  support  for  the  ranking  process  was 
developed  for  the  COMBDSS-D  prototype. 


Division  personnel  indicated  that,  upon  development  of  scenarios  and  the  use  of  financial 
analysis  to  assess  those  scenarios,  work  functions  would  need  to  be  re-ranked,  starting  at  a  different 
rank  level  for  each  District,  appropriation  code,  and  FCCD  group  (O&M).  This  has  been 
accomplished  'manually'  in  the  past,  by  comparison,  prioritization,  and  integration  of  work 
functions  from  District  paper  piles  into  a  single  Division  paper  pile.  This  new  Division  paper  pile 
was  then  assigned  new  Division  ranks  based  upon  the  meeting  participants’  decisions.  To  serve  the 
Division  needs,  the  design  team  modified  the  COMB  DSS-D  work  function  table,  including  a  field 
called  'newrank'.  Once  the  newrank  field  was  in  place,  an  additional  table  was  built  into  the 
COMB  DSS-D  prototype  that  allowed  the  Division  to  edit  the  starting  rank  for  each  District  by 
appropriation.  Thus,  by  providing  different  starting  ranks  for  each  District,  appropriation  code,  and 
FCCD  group  (O&M),  the  ranking  of  all  work  functions  up  to  a  certain  cutoff  (e.g.,  level  1)  was 
automated. 
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III.  SYSTEM  MODIFICATIONS 


OVERVIEW 

This  work  effort  was  funded  by  CECW-OM  to  enhance  and  maintain  the  COMB  DSS 
prototype  system  used  in  the  FY  94  budget  cycle.  The  design  team  coordinated  closely  with  system 
users  to  ensure  that  the  list  of  system  changes  were  comprehensive  and  could  be  accomplished  in 
the  designated  project  time  frame.  Following  the  ’94  budget  submission,  a  list  of  desired  changes 
and  enhancements  was  developed  by  the  project  team  in  April  of  1993,  prior  to  full  implementation 
of  the  Division  COMBDSS-D.  Certain  enhancements  to  the  Division  system  were  then  carried 
forward  to  the  modified  Headquarters  system.  A  second  meeting  to  review  work  to  date  was  held 
in  early  July  of  1993.  Additional  modifications  were  made  based  on  this  meeting,  and  the  modified 
system  was  delivered  in  mid-July  of  1993.  A  discussion  of  the  ’punch-list’,  additional  system 
enhancements,  and  a  summary  of  on-site  support  follows. 


MODIFICATION  LIST 

The  following  modification  list  is  broken  into  logical  components, * 71  '  created  towards  the 
end  of  the  development  of  the  original  COMB_DSS  prototype,  and  was  modified  at  an  initial 
meeting  between  system  users  and  design  team  personnel.  All  items  in  the  modification  list  were 
accomplished.  Text  found  in  italics  provides  additional  information  on  specific  system  changes 
where  necessary. 


Menu  Structure 

•  Revise  menu  structure  as  pulldowns  (Lotus  Style)  from  a  horizontal  menu: 

This  was  accomplished  by  incorporating  the  enhancements  made  to  the  COMB  DSS-D  menu 
structures  into  the  COMB  DSS  prototype  system  with  minor  modifications. 

•  Re-organize  menus  such  that  commonly  used  functions  are  available  where  needed  (e.g.,  list 
a  file) 

•  Create  and  run  scenario  at  same  menu  level. 

This  was  accomplished  by  modifying  the  menu  system. 

•  Move  reconstruct  scenario  to  scenario  management  and  execution. 
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Scenario  Management 

•  Ensure  unique  scenario  names  across  scenario  types,  not  just  within  a  scenario  type. 

This  is  the  case,  which  is  enforced  by  an  R.Base  rule. 

•  Do  not  allow  deletion  of  a  scenario  that  is  part  of  composite. 

•  Ensure  that  changing  a  scenario  name  does  not  allow  the  user  to  assign  one  which  already 
exists. 

•  Insure  that  all  parts  of  the  create,  delete  and  edit  scenario  process  are  operat  ectly. 

•  Provide  a  routine  which  updates  all  scenarios  that  are  affected  by  changes  in  other  scenarios. 
(At  issue  with  composite  scenarios). 

This  is  a  complex  process.  A  detailed  memo  was  prepared  to  explain  the  issues  relating  to 
scenario  dependencies,  and  methods  of  updating  scenarios. 

•  Extended  clone  scenario  capability,  which  allows  creation  of  SQL  scenarios  specific  to  each 
Division,  based  upon  a  master  existing  SQL  scenario.  Thus,  a  ’Clone  SQL  For  Divisions’ 
button  should  exist,  which  changes  the  scenario  name  automatically  and  adds  ’divnam  = 
"xxx"’  for  each  Division.  The  user  would  be  prompted  for  the  first  five  characters  of  the 
scenario  name,  and  the  Division  suffix  would  be  added  automatically  to  the  scenario  name 
and  the  description  field. 

•  Develop  the  capacity  for  SQL  scenarios  to  allow  matching  another  table  with  a  prompt  that 
includes  a  ’from’  clause,  as  well  as  a  ’where’  clause. 

The  entered  SQL  clause  is  now  parsed  by  the  program,  to  determine  if  a  'from  ’  clause 
exists,  and  handled  accordingly.  The  user  must  be  aware  of  the  possibility  of  creating 
queries  that  take  a  long  time  to  process. 

•  Develop  a  utility  on  the  menu  that  will  list  the  scenarios  (name,  number  and  type)  associated 
with  a  specific  work  function. 

An  additional  C-language  program  to  process  the  bitmap  file  to  obtain  all  scenarios  for  a 
given  work  function  was  created.  A  report,  including  the  scenario  name  and  description,  is 
generated  to  a  file,  and  then  displayed  on  the  screen. 

•  Develop  a  procedure,  within  financial  analysis,  to  load  the  default  column  headings  and 
default  totals  in,  prompt  for  title  editing,  then  generate  the  report,  as  opposed  to  the  current 
two-step  process  of  running  the  analysis  first,  then  editing  and  re-running. 
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Reports 


Fix  the  problem  with  sub-totals  not  adding  up  properly  in  Division  summary  reports. 

Add  the  scenario  name  for  each  column  as  a  footer  at  the  bottom  of  each  Financial  Analysis 
report. 

Check  District  subtotals  on  the  division-feature  cost  code  Financial  Analysis  report.  District 
subtotals  do  not  agree  with  other  reports. 

Many  of  the  reports  were  added  during  the  budget  analysis  process  and  are  not  integrated 
properly  into  the  menu  structure.  Organize  all  reports  and  place  them  within  the  menu 
structure. 


Bug  Fixes 

•  Fix  the  problem  with  ’set  extended  on’,  which  appears  to  be  associated  with  the 
inputs/outputs  of  the  crosstab  process,  which  reset  extended  to  off. 


Ranking 

•  Develop  an  ’all-in-one’  one-button  re-ranking  option. 

Tools 

•  Provide  a  scenario  dependency  report  for  a  single  chosen  scenario. 

•  Provide  is  a  diagram  of  all  the  command  files  used  in  the  system  showing  their  relationships 
to  the  menu,  and  to  their  internal  hierarchy. 


Data  Transfers 

•  Develop  transparent  data  transfer  approaches,  using  command  files  rather  than  Gateway. 

Procedures  were  developed  using  a  combination  of  R.  Base  SQL  commands  and  Clipper 
routines.  The  Clipper  routines  served  to  resolve  R.Base  naming  conflicts. 
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ON-SITE  SUPPORT 


On-site  support  in  this  budget  process  was  minimal  because  ( 1 )  the  analysis  time  frame  was 
somewhat  expanded,  (2)  Headquarters  personnel  used  the  system  in  the  previous  budget  cycle  and 
are  technically  capable  of  performing  system  changes  when  necessary,  and  (3)  system  modifications 
leading  up  to  the  analysis  provided  users  with  an  enhanced  decision  support  tool.  Design  team 
personnel  from  CECW-IWR-R  provided  the  majority  of  on-site  support  with  additional  phone 
support  occurring  as  required. 


SYSTEM  UPGRADE 

During  the  analysis  process,  Dave  Harmon  moved  the  system  from  R:Base  version  4.0a  to 
R:Base  version  4.5  (a  significant  package  upgrade  from  the  vendor).  In  this  conversion,  a  number 
of  problems  were  encountered  and  resolved  (in  italics)  as  follows: 

•  CONSTRAINT  field  in  the  WORKFUNC  table  is  a  now  a  reserved  word  and  must  be 
changed. 

Changed  CONSTRAINT  to  CONSTRANT,  where  found  in  system  tables.  Also  modified  the 
import  and  export  procedures  to  operate  on  the  revised  field  name. 

•  EDIT/ENTER  SQL  Scenarios  are  no  longer  working  properly. 

A  dummy  table  wax  used  in  the  form  to  hold  a  flag  indicating  whether  or  not  the  SQL 
scenario  should  be  tested  for  validity.  This  table  was  removed  and  replaced  with  a  variable 
field  which  performs  the  same  test. 

•  The  crosstab  statements  in  SCENREP7.CMD  had  to  be  modified.  FCCDPREF  was  changed 
to  FCCDPREFIX. 

This  process  involved  changing  the  name  of  an  internal  table.  R.  Base  4.5  recognizes 
unique  table  names  up  to  32  characters,  as  opposed  to  8  characters  in  previous  versions. 
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IV.  SUMMARY 


OVERVIEW 

This  current  work  effort  was  executed  successfully,  as  indicated  by  minimum  on-site  support 
required  by  the  design  team.  It  should  be  noted,  however,  that  the  COMBDSS  is  an  advanced 
learning  tool  and  requires  a  significant  learning  curve.  As  it  turns  out.  Headquarters  are  very 
technically  proficient  users  and  because  of  their  involvement  in  the  development  of  the  product, 
required  little  training.  As  the  Headquarters  system  continues  to  evolve,  changes  will  be  required 
and  can  be  implemented  by  members  of  the  design  team.  Additional  training  will  likely  be  required 
if  personnel  changes  are  made  at  the  Headquarters  level. 


OTHER  CONSIDERATIONS 

The  Operations  and  Maintenance  (O&M)  budget  is  under  review  by  an  O&M  Task  Force 
and  a  number  of  changes  are  envisioned  in  the  next  budget  cycle,  as  follows: 

•  Baseline  work  function  ranks  will  fall  between  10,000  -  19,999  and  will  include  dredging 
and  non-dredging  projects. 

•  Non-deferrable  project  ranks  will  fall  between  20,000  -  29,999  and  will  adhere  to  a  set  of 
justifying  rules,  including  new  requirements  or  mandated. 

•  Deferrable  project  ranks  will  fall  between  30,000  -  39,999  and  will  include  special  interest 
items. 

•  Addition  and  Betterment  (Improvement)  ranks  will  fall  between  40,000  -  49,999. 

•  Maintenance  and  Repair  ranks  will  fall  between  50,000  -  59,999  and  will  include  those  work 
functions  where  are  beyond  the  Corp’s  funding  ability. 

•  Feature  cost  codes  will  be  reduced  from  86  to  64. 

•  Sub-feature  cost  codes  will  be  reduced  from  241  to  177. 

Although  some  of  the  changes  detailed  above  will  have  implications  on  the  COMB  DSS,  all  are 
properly  aligned  with  the  scenario  concept  and  the  management  of  work  function  groups.  However, 
additional  requirements  may  be  placed  on  the  budget  process  which  cause  a  significant  effect  on  the 
way  the  COMB_DSS  handles  and  analyzes  data.  This  can  only  be  determined  when  the  new 
budget  guidance  is  finalized,  which  may  require  an  additional  budget  cycle  to  implement  in  the 
COMBDSS. 
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NEXT  STEPS 


Headquarters  has  requested  that  the  COMBDSS-D  prototype  applied  at  ORD  be  used  to 
handle  the  Division  ABS  procedures  in  the  FY  96  budget  cycle  (Calendar  year  1994).  That  is,  the 
COMB  DSS-D  will  be  used,  with  modification,  in  place  of  the  Division  ABS.  The  design  team 
feels  that  the  capabilities  made  available  to  ORD  in  the  COMB  DSS-D  prototype  can  be  extended 
to  make  the  system,  through  training,  a  Corps-wide  system.  A  distributed  Division  system  will 
require  field  interviews  and  a  demonstration  of  the  existing  prototype,  which  will  serve  as  the  basis 
for  a  concept  document.  From  the  concept  document,  iterative  software  prototypes  will  be 
developed  and  documented,  with  the  final  prototype  slated  for  training  and  implementation  as  the 
first-cut  distributed  system. 

The  District  ABS  is  currently  being  ported  to  Microsoft  Access  (a  windows-based  relational 
database  management  system)  with  a  Visual  Basic  (also  a  product  of  Microsoft)  windows-based 
front-end  (interface).  The  port  is  being  performed  by  Construction  Engineering  Research 
Laboratory  (CERL)  under  the  guidance  of  personnel  from  CECW-OM.  The  system  is  currently  in 
design  phase,  and  is  slated  for  implementation  in  the  1997  budget  cycle  (calendar  year  1995).  At 
that  time,  or  potentially  concurrently,  a  windows-based  design  will  be  considered  for  the 
COMB  DSS  and  the  COMB  DSS-D.  The  desire,  in  the  long-term,  is  to  arrive  at  an  integrated 
system,  in  which  the  COMB  DSS  and  the  ABS  operate  as  a  single  unit,  with  differences,  as 
required,  across  levels. 
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